docs/content/docs/shared/getting-started/quickstart.mdx-231-231 (1)

231-231: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Correct the sample queue statistics.

This walkthrough enqueues one job, so a successful run should show completed: 1, not completed: 5. Use 1 or placeholder values to keep the output consistent with the preceding steps.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/getting-started/quickstart.mdx` at line 231, The
quickstart queue statistics sample shows an incorrect completed-job count.
Update the displayed output from completed: 5 to completed: 1, keeping the other
values consistent with the preceding steps.

docs/content/docs/shared/guides/core/scheduling.mdx-85-106 (1)

85-106: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Avoid a permanently stale periodic payload.

Both examples pass "2026-06-16" as a fixed argument, so every future daily run receives that same past date. Compute the date inside the handler or pass a scheduler-provided/current date instead.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/core/scheduling.mdx` around lines 85 - 106,
Replace the hard-coded "2026-06-16" periodic argument in the Python digest
handler and Node "digest" task registration with logic that derives the current
run date inside each handler or uses a scheduler-provided date, ensuring every
daily execution receives the correct date.

docs/content/docs/shared/guides/resources/interception.mdx-304-309 (1)

304-309: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Validate the amount at runtime before the comparison. as number is compile-time only, so non-numeric values, NaN, and Infinity can slip past this check. Use a runtime type/finite guard before rejecting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/resources/interception.mdx` around lines 304
- 309, Update the chargeCard handler in the queue.intercept callback to validate
args[0] at runtime before comparing it: require a number and
Number.isFinite(args[0]), then reject invalid or negative amounts; otherwise
return Interception.pass(). Remove reliance on the compile-time as number
assertion.

docs/content/docs/shared/guides/reliability/retries.mdx-92-100 (1)

92-100: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep jitter within the documented maximum delay.

With delay = min(M, B * 2^retry_count) + jitter, the actual delay can exceed M, despite max_retry_delay being documented as a cap. Use min(M, B * 2^retry_count + jitter) or clarify that the cap excludes jitter.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/reliability/retries.mdx` around lines 92 -
100, The retry delay formula in the reliability guide incorrectly allows jitter
to exceed the documented maximum. Update the scheduler description to apply
jitter before the cap, using min(M, B * 2^retry_count + jitter), and ensure the
surrounding defaults or examples consistently describe M as the true maximum
delay.

docs/content/docs/shared/guides/workflows/canvas.mdx-551-554 (1)

551-554: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Correct the “No imports needed” comparison.

The Python canvas examples still import chain, group, chord, and Queue. Change this to “No workflow-definition imports needed” or similar; the current wording is misleading.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/workflows/canvas.mdx` around lines 551 - 554,
The comparison table’s “Setup” row incorrectly says Canvas requires no imports;
update it to “No workflow-definition imports needed” or equivalent, reflecting
the imports used by the canvas examples while distinguishing them from DAG
workflow imports.

docs/content/docs/shared/more/examples/benchmark.mdx-255-257 (1)

255-257: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Use the actual TypeScript runner here. docs/package.json doesn’t define tsx/ts-node, so node benchmark.ts isn’t runnable as written; replace it with the repo’s documented command or a compile-then-run step.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/more/examples/benchmark.mdx` around lines 255 - 257,
Replace the `node benchmark.ts` command in the benchmark example with the
repository’s documented TypeScript execution command, or provide commands that
compile `benchmark.ts` and then run the generated JavaScript; ensure the
documented steps work with the dependencies defined in `docs/package.json`.

docs/content/docs/shared/guides/extensibility/serializers.mdx-249-253 (1)

249-253: 🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Describe the encryption strength accurately.

The page calls EncryptedSerializer AES-256-GCM, but the documented key lengths also allow AES-128 and AES-192. Use “AES-GCM” generally and state that strength depends on key length.

Also applies to: 414-422

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/extensibility/serializers.mdx` around lines
249 - 253, Update the EncryptedSerializer description to refer to AES-GCM rather
than AES-256-GCM, and state that encryption strength depends on the configured
key length, including the supported AES-128, AES-192, and AES-256 variants.
Apply the same wording to the corresponding repeated section.

docs/content/docs/shared/guides/operations/troubleshooting.mdx-461-462 (1)

461-462: 🚀 Performance & Scalability | 🟡 Minor | ⚡ Quick win

Clarify Postgres and Redis space reclamation.

Standard Postgres autovacuum reuses free space but does not necessarily shrink files, and Redis key expiry is not automatic when the page says Node/Java have no built-in TTL. Clarify that SQLite needs VACUUM, Postgres reuses space through vacuuming, and Redis deletion/expiry depends on configuration.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/operations/troubleshooting.mdx` around lines
461 - 462, Update the disk-space reclamation guidance after purging: state that
SQLite requires VACUUM, Postgres vacuuming generally reuses free space without
necessarily shrinking database files, and Redis deletion or key expiry depends
on its configured expiration and cleanup behavior. Align the surrounding
Node/Java TTL wording with this clarification.

docs/content/docs/shared/guides/operations/testing.mdx-657-669 (1)

657-669: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Close the worker in the synchronization example.

The snippet creates a worker without stopping or closing it, despite the later warning that leaked workers continue polling across tests. Use try-with-resources or a finally block.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/operations/testing.mdx` around lines 657 -
669, Update the synchronization example to ensure the Worker created in the
CountDownLatch snippet is closed after use, using try-with-resources or a
finally block around the worker lifecycle. Keep the existing event registration
and synchronization behavior intact.

docs/content/docs/shared/guides/extensibility/middleware.mdx-171-174 (1)

171-174: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Document Python’s enqueue-hook signature separately.

Python receives mutable task_name, args, kwargs, and options; it does not receive an EnqueueContext object as implied here. Clarify the wording for Python versus Node/Java.

Suggested wording

- the context it receives is **mutable** — use it to validate, redact, or reshape what actually gets enqueued.
+ the enqueue arguments are mutable — in Python, use `args`, `kwargs`, and `options`; Node and Java expose a mutable enqueue context.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/extensibility/middleware.mdx` around lines
171 - 174, Update the on_enqueue/onEnqueue documentation to distinguish Python
from Node/Java: explain that Python’s hook receives mutable task_name, args,
kwargs, and options directly, while Node/Java receive a mutable EnqueueContext
object; remove wording that implies Python receives EnqueueContext.

docs/content/docs/shared/guides/operations/testing.mdx-482-505 (1)

482-505: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Assert the waitFor result.

waitFor returns false on timeout, but this example ignores the return value. The example can therefore pass even when the resource is never resolved.

- await waitFor(() => db.resolutions === 1);
+ expect(await waitFor(() => db.resolutions === 1)).toBe(true);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/operations/testing.mdx` around lines 482 -
505, Update the `mockResource()` example to assert that `waitFor` returns true,
rather than ignoring its result. Wrap the existing `waitFor(() => db.resolutions
=== 1)` call in the documentation’s assertion mechanism so the example fails
when the resource is not resolved within the timeout.

docs/content/docs/shared/guides/operations/keda.mdx-316-320 (1)

316-320: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use metric-neutral wording for the shared KEDA manifests.

The prose describes pending jobs, but the Java scaler reports pending + running. Consequently, the same targetValue has different scaling semantics across SDKs. Describe this as outstanding work or add explicit Java-specific guidance beside each manifest.

Also applies to: 356-360

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/operations/keda.mdx` around lines 316 - 320,
The shared KEDA manifest descriptions around “ScaledObject (HTTP trigger)” must
avoid SDK-specific “pending job count” wording because Java reports pending plus
running work. Replace these references with metric-neutral wording such as
“outstanding work,” including the corresponding section around the other
affected manifest, or add explicit Java-specific guidance beside each manifest.

docs/content/docs/shared/guides/integrations/sentry.mdx-1-3 (1)

1-3: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Align the page description with the Java event tags.

The frontmatter promises task name, job ID, and queue tags, but the Java section documents only taskito.task and taskito.job. Either add the queue tag to Java events or qualify the description as SDK-specific.

Suggested metadata correction

-description: "Report task failures to Sentry, tagged by task name, job id, and queue."
+description: "Report task failures to Sentry with SDK-specific task and job metadata."

Also applies to: 139-148

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/integrations/sentry.mdx` around lines 1 - 3,
Update the Sentry page frontmatter description to accurately reflect the
documented Java event tags: either document and implement the queue tag for Java
events, or qualify the description as applying only to SDKs that provide it.
Keep the metadata consistent with the Java section describing taskito.task and
taskito.job.

docs/content/docs/shared/guides/operations/deployment.mdx-274-279 (1)

274-279: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Add or remove the missing ENV declaration.

The callout says to keep an ENV TASKITO_DB_PATH=... line from the Dockerfile above, but that line is absent. Add it near VOLUME /data, or remove the reference so the instructions match the displayed Dockerfile.

Suggested fix

 # Store the database in a volume
 VOLUME /data
+ENV TASKITO_DB_PATH=/data/taskito.db

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/content/docs/shared/guides/operations/deployment.mdx` around lines 274 -
279, Add the missing `ENV TASKITO_DB_PATH=...` declaration to the displayed
Dockerfile example near `VOLUME /data`, or update the callout to remove its
reference; ensure the deployment instructions and Dockerfile remain consistent.

docs/scripts/parity/checks/drift.mjs-18-24 (1)

18-24: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Normalize topics through the shared slug helper.

topicOf treats guides/foo/index.mdx and guides/foo.mdx as different topics, even though the routing contract maps them to the same URL. This can silently miss SDK drift during migrations.

Proposed fix

-import { isSdk } from "../../../app/lib/sdk-registry.ts";
+import { isSdk } from "../../../app/lib/sdk-registry.ts";
+import { relPathToSlug } from "../../../app/lib/doc-slugs.ts";

 function topicOf(rel) {
-  const [head, ...rest] = rel.split("/");
-  if (!isSdk(head) || rest.length === 0) {
+  const [, sdk, ...topicParts] = relPathToSlug(rel).split("/");
+  if (!isSdk(sdk) || topicParts.length === 0) {
     return null;
   }
-  const topic = rest.join("/").replace(/\.mdx$/, "");
+  const topic = topicParts.join("/");
-  return { sdk: head, topic: NAME_EQUIVALENTS.get(topic) ?? topic };
+  return { sdk, topic: NAME_EQUIVALENTS.get(topic) ?? topic };
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/scripts/parity/checks/drift.mjs` around lines 18 - 24, Normalize the
topic path in topicOf using the shared slug helper before applying
NAME_EQUIVALENTS, so directory index paths such as guides/foo/index.mdx resolve
to the same topic as guides/foo.mdx. Preserve the existing SDK validation and
return structure, and locate the shared helper already used for route slug
normalization.

docs/app/lib/manifest.ts (1)

10-12: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Share DocMeta across the docs manifest boundary
docs/app/virtual-docs-manifest.d.ts only types DOCS; it doesn’t bridge DocMeta, so docs/app/lib/manifest.ts and docs/vite-plugin-docs-manifest.ts still duplicate the same shape. A shared type-only module would remove the drift risk with no runtime cost.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/app/lib/manifest.ts` around lines 10 - 12, Introduce a shared type-only
module defining DocMeta, then import and use it in both docs/app/lib/manifest.ts
and docs/vite-plugin-docs-manifest.ts. Update
docs/app/virtual-docs-manifest.d.ts to re-export or reference the shared DocMeta
type while retaining the DOCS declaration, and remove the duplicated DocMeta
shape from both consumers.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes